다국어 지원¶

문자 데이터¶

콜레이션을 적용할 수 있는 데이터의 타입은 VARCHAR, CHAR, ENUM 타입이다.

문자셋(charset, codeset)은 어떤 타입에 대해 문자가 저장되는 방식 또는 일련의 바이트가 하나의 문자를 구성하는 방식을 제어한다. CUBRID는 UTF-8, ISO-8859-1, EUC-KR 문자셋을 지원하며, UTF-8에 대해 코드포인트 10FFFF(4 바이트까지 인코딩됨)까지만 지원한다. 예를 들어, 문자 "Ç"는 코드셋 ISO-8859-1에서 1 바이트(C7)으로 인코딩되지만, UTF-8에서는 2 바이트(C3 88)로 인코딩된다. 반면, EUC-KR에서 이 문자는 사용할 수 없다.

콜레이션은 문자를 비교하는 방법을 결정한다. 사용자는 흔히 콜레이션을 통해 대소문자를 구분하지 않거나 구분한다. 예를 들어 "ABC"와 "abc"는 대소문자 구분 무시(case insensitive) 콜레이션에서는 동일한 반면, 대소문자 구분(case sensitive) 콜레이션에서는 동일하지 않다. 또한 콜레이션에 따라 비교 결과가 "ABC" > "abc"가 되거나 "ABC" < "abc"가 될 수 있다.

콜레이션은 대소문자 비교 이상의 것을 의미한다. 콜레이션은 두 문자열 간에 관계를 결정하여 LIKE와 같은 문자열 매칭에 사용되거나 인덱스 스캔에서 영역을 계산하는데 사용된다.

CUBRID에서 콜레이션은 문자셋을 포함한다. 예를 들어, "utf8_en_ci"과 "iso88591_en_ci"은 대소문자를 구분하지 않는 비교이지만 다른 문자셋에서 동작한다. ASCII 범위에서 비교 결과는 비슷하지만 UTF-8 인코딩은 가변적인 바이트 수에 따라 동작해야 하기 때문에 "utf8_en_ci" 콜레이션에서 비교 수행 속도가 더 느리다.

• "'a' COLLATE iso88591_en_ci"는 "_iso88591'a' COLLATE iso88591_en_ci"를 나타낸다.
• "'a' COLLATE utf8_en_ci"는 "_utf8'a' COLLATE utf8_en_ci"를 나타낸다.

모든 문자 데이터 타입은 자릿수(precision)를 지원한다. 고정 길이 문자(CHAR)는 특별히 다루어져야 한다. CHAR 타입의 값은 자릿수를 채워서 저장된다. 예를 들어 "abc"를 CHAR(5) 칼럼에 저장하면, "abc "(2 개의 공백 문자가 패딩됨)를 저장하게 된다. 공백 문자(ASCII 32, Unicode 0020)는 대부분 문자에서 사용하는 패딩 문자이다. 하지만 EUC-KR 문자셋에서 패딩 문자는 두 개 바이트(A1 A1)로 저장된 하나의 문자로 구성된다.

관련 용어¶

• 문자셋(character set): 기호를 인코딩(어떤 기호에 특정 번호를 부여)한 집합

• 콜레이션(collation): 문자셋에서 문자를 비교하기 위한, 데이터 정렬을 위한 규칙의 집합

• 로캘(locale): 사용자의 언어 및 국가에 따라 숫자 형식, 캘린더(월의 이름, 요일의 이름), 날짜/시간 형식, 콜레이션 등을 정의하는 인자들의 집합. 로캘은 언어에 대한 지역화(localization)를 정의한다. 로캘의 문자셋은 월의 이름 및 다른 데이터가 어떻게 인코딩되는지를 나타낸다. 로캘은 최소한 하나의 언어 식별자와 영역 식별자로 구성되어 있으며 language[_territory][.codeset]으로 표현한다. (예를 들어 UTF-8 인코딩을 쓰는 오스트레일리아 영어는 en_AU.utf8로 표기한다.)

• 유니코드 정규화(Unicode normalization): 모양이 같은 여러 문자들이 있을 경우 기준에 따라 이를 하나로 통합하는 것. CUBRID는 입력 시에는 NFC(Normalization Form C) 형식(분해된 코드포인트에서 결합된 코드포인트로 변환)을 사용하고, 출력 시에는 NFD(Normalization Form D) 형식(결합된 코드포인트에서 분해된 코드포인트로 변환)을 사용한다. 하지만, CUBRID는 예외적으로 규범적 등가(canonical equivalence) 규칙을 적용하지 않는다.

  예를 들어, 일반적인 NFC 규칙에 따르면 규범적 등가 규칙을 적용하여 코드포인트 212A(캘빈 기호 K)는 코드포인트 4B(ASCII 코드 대문자 K)로 변환된다. CUBRID는 규범적 등가 규칙에 의한 변환을 수행하지 않도록 하여 정규화 알고리즘을 더 간단하고 빠르게 하였고, 따라서 역변환도 수행하지 않는다.

• 규범적 등가(canonical equivalence): 시각적으로 구별이 불가능하고 텍스트 비교상 정확히 동일한 의미를 가지는 문자. 한 예로 'A'에 옹스트롬(Angstrom) 기호가 있는 'Å'가 있는데, 'Å'(유니코드 U+212B)와 라틴어 'A'(유니코드 U+00C5)는 모양이 같고 코드포인트가 다르지만 분해된 결과는 'A'와 U+030A로 같으므로 규범적 등가이다.

• 호환성 등가(compatibility equivalence): 동일한 문자나 문자 시퀀스의 대체 표현 문자. 예로는 숫자 '2'(유니코드 U+0032)와 위 첨자 '²'(유니코드 U+00B2)가 있는데, '²' 는 숫자 '2'의 다른 형태이긴 하지만 시각적으로 구별되고 의미도 다르기 때문에 규범적 등가에 해당되지 않는다. '2²'를 NFC로 정규화하면 규범적 등가를 사용하기 때문에 '2²'가 유지되지만, NFKC 방식에서는 '²'가 호환성 등가인 '2'로 분해된 후 결합되어 '22'로 바뀔 수 있다. CUBRID의 유니코드 정규화에서는 호환성 등가 규칙도 적용하지 않는다.

유니코드 정규화에 대한 설명은 유니코드 정규화 를 참고하며, 보다 자세한 내용은 http://unicode.org/reports/tr15/를 참고한다.

유니코드 정규화 관련 시스템 파라미터에서 기본으로 설정되는 값은 unicode_input_normalization=no이고 unicode_output_normalization=no이다. 이 파라미터에 대한 보다 자세한 설명은 구문/타입 관련 파라미터 를 참고한다.

로캘 속성¶

로캘은 다음과 같은 속성들로 정의된다.

• 문자셋(코드셋): 여러 바이트를 하나의 문자로 해석하는 방법을 정의한다. 유니코드에서는 여러 개의 바이트가 하나의 코드포인트(codepoint)를 구성하는 것으로 해석된다.
• 콜레이션(collation): LDML(UNICODE Locale Data Markup Language) 파일의 로캘 데이터에 여러 콜레이션을 지정할 수 있는데, 이 중에 마지막으로 명시된 것이 기본(default) 콜레이션으로 사용된다.
• 알파벳(대소문자 규칙): 하나의 로캘 데이터는 테이블 이름, 칼럼 이름과 같은 식별자용과 사용자 데이터용으로 최대 두 종류의 알파벳을 가질 수 있다.
• 캘린더: 요일 이름, 월의 이름, 오전/오후(AM/PM) 표시
• 숫자 표기: 자릿수 구분 기호
• 텍스트 변환 데이터: CSQL 콘솔 변환용. 선택 사항
• 유니코드 정규화 데이터: 모양이 같은 여러 문자들이 있을 경우 이를 기준에 따라 하나의 값으로 통합하는 정규화를 수행하여 변환된 데이터. 정규화 이후에는 로캘이 달라도 모양이 같은 문자는 같은 코드값을 가지며, 각 로캘은 이 정규화 기능을 활성화 또는 비활성화할 수 있다.

콜레이션 속성¶

콜레이션(collation)은 문자열의 비교 및 정렬 규칙의 집합으로, CUBRID에서 콜레이션은 다음과 같은 속성(property)을 갖는다.

• 세기(strength): 기본 비교 항목들(문자들)이 어떻게 다른지 나타내는 측정 기준이다. 이것은 선택도(selectivity)에 영향을 준다. LDML 파일에서 콜레이션의 세기는 네 가지 수준(level)으로 설정할 수 있다. 예를 들어, 대소문자 구분이 없는 콜레이션은 level = "secondary" (2) 또는 "primary" (1)로 설정해야 한다.
• 확장(expansion) 과 축약(contraction) 지원 여부

각각의 칼럼이 콜레이션을 가질 수 있기 때문에, LOWER(), UPPER() 함수 등을 적용할 때 해당 콜레이션의 기본 언어에서 정의한 로캘의 대소문자 구분 규칙(casing rule)이 사용된다.

콜레이션 속성에 따라 일부 콜레이션에서 다음과 같은 특정 CUBRID 최적화가 동작하지 않을 수 있다.

• LIKE 구문 재작성: 같은 가중치(weight)에 여러 개의 다른 문자를 매핑하는 콜레이션, 예를 들어 대소문자 구분이 없는 콜레이션에서는 LIKE 구문이 재작성되지 않는다.
• 커버링 인덱스 스캔: 같은 가중치에 여러 개의 다른 문자를 매핑하는 콜레이션에서는 커버링 인덱스 스캔이 동작하지 않는다(커버링 인덱스 참고).

이에 관한 보다 자세한 설명은 콜레이션 설정으로 인한 영향 을 참고하면 된다.

콜레이션 명명 규칙¶

콜레이션 이름은 다음 규칙을 따른다.

<charset>_<lang specific>_<desc1>_<desc2>_...

• <charset>: 문자셋 이름. iso88591, utf8, euckr이 있다.
• <lang specific>: 지역/언어를 나타내며, en, de, es, fr, it, ja, km, ko, tr, vi, zh, ro가 있다. 특정 언어를 나타내지 않을 때는 "gen"으로 일반적인 정렬 규칙을 의미한다.
• <desc1>_<desc2>_...: 대부분 LDML 콜레이션에만 적용되며 각각 다음의 의미를 갖는다.
  • ci: 대소문자 구분 안 함. LDML 파일에서 다음을 설정하면 적용된다: strength="secondary" caseLevel="off" caseFirst="off"
  • cs: 대소문자 구분. 기본적으로 모든 콜레이션은 대소문자를 구분한다. LDML 파일에서 다음을 설정하면 적용된다: strength="tertiary"
  • bin/binary: 정렬 순서가 코드포인트의 순서와 똑같음. 메모리의 바이트 순서를 비교하면 거의 같은 결과가 나오는데, 공백 문자와 EUC의 더블 바이트 패딩 문자는 "bin" 콜레이션에서 항상 0으로 정렬된다. LDML 파일에는 bin 콜레이션을 설정하는 방법이 없는데(bin 콜레이션은 이미 내장되어 있음), LDML 파일에서 다음을 설정하면 비슷하게 적용된다: strength="quaternary" 또는 strength="identical"
  • ai: 악센트 구분 안 함. 예를 들어, 'Á'는 'A'와 같은 순서이다. 이는 또한 대소문자를 구분하지 않는다. LDML 파일에서 (strength="primary")를 설정하면 적용된다.
  • uca: UCA(Unicode Collation Algorithm) 기반 콜레이션을 의미함. 내장된 변형 콜레이션과 구별하기 위해서만 사용된다. 즉, 모든 LDML 콜레이션은 UCA를 기반으로 하지만 짧은 이름을 유지하기 위해 "_uca"가 생략되며, 예외적으로 'utf8_ko_cs_uca', 'utf8_tr_cs_uca' 이 두 개의 콜레이션만 내장된 'utf8_ko_cs', 'utf8_tr_cs' 콜레이션과 구별하기 위해 사용된다.
  • exp: 다른 콜레이션들이 문자 단위로 비교하는 것에 반해, 확장 은 전체 단어 매칭/비교 알고리즘을 사용한다. 이 콜레이션은 좀더 복잡한 알고리즘을 사용하므로 훨씬 느릴 수 있지만, 알파벳 정렬에 유용할 수 있다. LDML 파일에 다음이 명시되어야 한다: CUBRIDExpansions="use"
  • ab: 역순 액센트(accent backwards). 특히 캐나다 프랑스어에만 적용되는데, UCA 2단계(액센트 가중치를 저장)는 문자열의 끝에서부터 시작 방향으로 비교된다. 이 콜레이션 설정은 오직 확장 이 활성화되는 경우에만 사용될 수 있다. "ab" 설정은 다음 정렬을 허용한다.
    • 일반적인 액센트 순서: cote < coté < côte < côté
    • 역방향 액센트 순서: cote < côte < coté < côté
  • cbm: 축약 영역 매칭(contraction boundary match). 확장 과 축약 이 있는 콜레이션의 특별한 콜레이션이며, 매칭되는 문자열에서 축약 이 발견될 때 동작하는 방법을 설정한다. 콜레이션의 축약 을 "ch"로 정의했다고 가정하자. 그러면 일반적으로 "bac"라는 패턴은 문자열 "bachxxx"와는 매칭되지 않는다. 그러나 콜레이션이 "축약을 시작하는 문자 매칭"을 허용하도록 설정되면, 앞서 말한 문자열들은 매칭된다. 이러한 식으로 동작하는 콜레이션은 'utf8_ja_exp_cbm' 밖에 없는데, 일본어 정렬은 무수히 많은 축약 을 요구한다.

콜레이션 이름은 동적으로 생성되지 않는다. LDML에 정의되어 있으며, 콜레이션 설정을 반영해야 한다.

콜레이션 이름은 콜레이션의 내부적인 ID에 영향을 준다. CUBRID는 256 개의 콜레이션을 허용하며, 각 식별자들은 다음과 같이 등록된다.

• 0 - 31: 내장된(built-in) 콜레이션(이름과 식별자가 제품에 포함됨)
• 32 - 46: 언어 부분에 "gen"을 가지는 LDML 콜레이션
• 47 - 255: 나머지 LDML 콜레이션

CUBRID가 제공하는 모든 로캘을 데이터베이스에 포함하고 싶다면, 먼저 $CUBRID/conf 디렉터리의 cubrid_locales.all.txt 파일을 cubrid_locales.txt 파일로 복사한다. 그리고, make_locale 스크립트(확장자가 Linux는 .sh, Windows는 .bat)를 실행하면 된다. make_locale 스크립트에 대한 자세한 설명은 2단계: 로캘 컴파일하기를 참고하면 된다.

기존의 데이터베이스에 새로 추가한 로캘 정보를 포함하고 싶다면 cubrid synccolldb <dbname>을 실행한다. 이에 대한 자세한 설명은 데이터베이스 콜레이션을 시스템 콜레이션에 동기화를 참고하면 된다.

LDML 파일로 정의된 로캘을 모두 포함하는 경우 CUBRID는 다음의 콜레이션을 가진다.

로캘 저장 위치¶

CUBRID는 로캘 설정을 위해 여러 디렉터리와 파일들을 사용한다.

• $CUBRID/conf/cubrid_locales.txt 파일: 사용할 로캘 리스트를 포함하는 초기 설정 파일
• $CUBRID/conf/cubrid_locales.all.txt 파일: cubrid_locales.txt 와 같은 구조를 갖는 초기 설정 파일의 템플릿. 사용자가 직접 정의하지 않아도 되는 CUBRID가 현재 지원하는 CUBRID 로캘 버전의 전체 리스트를 포함한다.
• $CUBRID/locales/data 디렉터리: 로캘 데이터를 생성하는데 필요한 파일들을 포함한다.
• $CUBRID/locales/loclib 디렉터리: 로캘 데이터를 포함하는 공유 라이브러리 생성을 위한 C 언어로 작성된 locale_lib_common.h 헤더 파일과 빌드를 위한 makefile을 포함한다.
• $CUBRID/locales/data/ducet.txt 파일: 코드포인트, 축약과 확장 등과 같은 기본적인 범용 콜레이션 정보와 이들의 가중치 값을 표현하는 파일로, 이 정보들은 유니코드 컨소시엄에 의해 제정된 표준을 따른다. 자세한 사항은 http://unicode.org/reports/tr10/#Default_Unicode_Collation_Element_Table 을 참고한다.
• $CUBRID/locales/data/unicodedata.txt 파일: 대소문자 구별, 분해, 정규화 등 각각의 유니코드 코드 포인트를 포함하는 파일로, CUBRID는 대소문자 구분 규칙을 결정하기 위해 이 파일을 사용한다. 더 많은 정보는 http://www.ksu.ru/eng/departments/ktk/test/perl/lib/unicode/UCDFF301.html 을 참고한다.
• $CUBRID/locales/data/ldml 디렉터리: common_collations.xml 파일과 cubrid_<locale_name>.xml 형식의 이름을 지니는 XML 파일들을 포함한다. common_collations.xml 파일은 모든 로캘에서 공유되는 콜레이션 정보를 표현하며, 각각의 cubrid_<locale_name>.xml 파일은 해당 언어에 대한 로캘 정보를 표현한다.
• $CUBRID/locales/data/codepages 디렉터리: 한 바이트 코드 페이지들을 위한 코드 페이지 콘솔 변환용 파일들(8859-1.txt, 8859-15.txt, 8859-9.txt)과 멀티바이트 코드 페이지를 위한 코드 페이지 콘솔 변환용 파일들(CP1258.txt, CP923.txt, CP936.txt, CP949.txt)을 포함한다.
• $CUBRID/bin/make_locale.sh 파일 또는 %CUBRID%\bin\make_locale.bat 파일(Windows): 로캘 데이터를 표현하는 공유 라이브러리를 생성하기 위해 사용되는 스크립트 파일이다.
• $CUBRID/lib 디렉터리: 로캘 데이터를 표현하는 공유 라이브러리 파일이 저장된다.

1단계: 로캘 선택¶

사용하려는 로캘을 $CUBRID/conf/cubrid_locales.txt 에 지정한다. 모두 선택하거나 부분만 선택할 수 있다.

CUBRID가 현재 지원하는 로캘은 en_US, de_DE, es_ES, fr_FR, it_IT, ja_JP, km_KH, ko_KR, tr_TR, vi_VN, zh_CN, ro_RO이며, 이 목록은 $CUBRID/conf/cubrid_locales.all.txt에 작성되어 있다.

각 로캘 이름 및 언어, 사용 국가는 다음 표와 같다.

<lang_name>  <LDML file>                                        <lib file>
ko_KR        /home/CUBRID/locales/data/ldml/cubrid_ko_KR.xml    /home/CUBRID/lib/libcubrid_ko_KR.so

2단계: 로캘 컴파일하기¶

1단계에서 설명한 요구사항들이 충족되었다면 로캘 데이터를 컴파일할 수 있다.

CUBRID에 내장된 로캘을 사용한다면 사용자 로캘 라이브러리를 컴파일하지 않고 사용할 수 있으므로 2단계를 생략할 수 있으나, 내장된 로캘과 라이브러리 로캘에는 차이가 있다. 이와 관련하여 내장된 로캘과 라이브러리 로캘을 참고한다.

로캘 데이터를 컴파일하려면 make_locale 스크립트(파일의 확장자는 Linux에선 .sh, Windows에선 .bat)를 사용한다. 이 스크립트는 $CUBRID/bin 디렉터리에 위치하며, 이 경로가 $PATH 환경 변수에 포함되어야 한다. 여기서 $CUBRID, $PATH 는 Linux의 환경 변수이며, Windows에서는 %CUBRID%, %PATH%이다.

사용법은 make_locale.sh -h (Windows는 make_locale /h 이며, Visual C++ 2005, 2008 또는 2010 중 하나가 설치되어 있어야 한다.) 명령을 실행하면 출력되며, 사용 구문은 다음과 같다.

make_locale.sh [options] [locale]

options ::= [-t 32 | 64 ] [-m debug | release]
locale ::= [de_DE | es_ES | fr_FR | it_IT | ja_JP | km_KH | ko_KR | tr_TR | vi_VN | zh_CN |ro_RO]

• options
  • -t: 32비트 또는 64비트 중 하나를 선택한다(기본값: 32).
  • -m: release 또는 debug 중 하나를 선택한다. 일반적인 사용을 위해서는 release를 선택한다(기본값: release). debug 모드는 로캘 라이브러리를 직접 작성하려는 개발자를 위해 제공한다.
• locale: 빌드할 라이브러리의 로캘 이름. locale 이 주어지지 않으면, 설정한 모든 로캘의 데이터를 포함하도록 빌드된다. 이 경우 $CUBRID/lib 디렉터리에 libcubrid_all_locales.so (Windows의 경우 .dll)라는 이름으로 라이브러리 파일이 저장된다.

여러 로캘에 대해서 사용자 정의 로캘 공유 라이브러리를 만들려면 다음 두 가지 방법 중 하나를 사용할 수 있다.

• 모든 로캘을 포함하는 하나의 라이브러리 생성: 다음과 같이 로캘을 명시하지 않고 실행한다.

  make_locale.sh -t64                        # Build and pack all locales (64/release)
  

• 하나의 로캘만을 포함하는 라이브러리를 여러 개 반복하여 생성: 다음과 같이 하나의 언어를 지정한다.

  make_locale.sh -t 64 -m release ko_KR
  

이와 같은 두 가지 방법 중에서 첫 번째 방법을 사용하는 것을 권장한다. 공유 라이브러리를 생성하면 로캘들 간에 공유될 수 있는 데이터들이 중복되지 않기 때문에 메모리 사용량을 줄일 수 있다. 첫 번째 방식으로 지원하는 모든 로캘을 포함하도록 생성하면 약 15MB 정도 크기의 라이브러리가 생성되며, 두 번째 방식으로 생성할 경우에는 언어에 따라서 1MB에서 5MB 이상의 크기의 라이브러리가 생성된다. 또한 첫 번째 방식에서는 두 번째 방식을 사용했을 때에 서버 재시작 시점 등에 발생되는 런타임 오버헤드가 없기 때문에 런타임에도 유리하다.

3단계: 특정 로캘을 사용하기 위해 CUBRID 설정하기¶

DB 생성 시 로캘 지정을 통해 오직 하나의 로캘을 기본 로캘로 지정할 수 있다.

기본 로캘을 지정하여 기본 캘린더가 정의되지만, intl_date_lang 시스템 파라미터를 설정하면 기본 로캘 설정보다 우선 적용된다.

• 로캘의 값은 <locale_name>[.utf8 | .iso88591]과 같이 설정한다. (예: tr_TR.utf8, en_US.iso88591, ko_KR.utf8)
• intl_date_lang 시스템 파라미터의 값은 <locale_name>과 같이 설정한다. <locale_name>으로 사용할 수 있는 값은 1단계: 로캘 선택을 참고한다.

4단계: 선택한 로캘 설정으로 데이터베이스 생성하기¶

cubrid createdb <db_name> <locale_name.charset>을 실행하면, 해당 언어와 문자셋을 사용하는 데이터베이스가 생성된다. 일단 데이터베이스가 생성되면 해당 데이터베이스에 부여된 로캘 설정은 바꿀 수 없다.

문자셋과 로캘 이름은 db_root라는 시스템 카탈로그 테이블에 저장되며, 생성 시점의 설정과 다른 설정을 사용하여 데이터베이스를 구동할 수 없다.

5단계(선택 사항): 로캘 파일의 수동 검증¶

로캘 라이브러리의 내용들을 dumplocale 유틸리티를 이용해서 사람이 읽을 수 있는 형태로 출력할 수 있다. 사용법은 cubrid dumplocale -h로 출력할 수 있다.

cubrid dumplocale [options] [language-string]

options ::= -i|--input-file <shared_lib>
            -d|--calendar
            -n|--numeric
            {-a |--alphabet=}{l|lower|u|upper|both}
            -c|--codepoint-order
            -w|--weight-order
            {-s|--start-value} <starting_codepoint>
            {-e|--end-value} <ending_codepoint>
            -k
            -z

language-string ::= de_DE | es_ES | fr_FR | it_IT | ja_JP | km_KH | ko_KR | tr_TR | vi_VN | zh_CN | ro_RO

• dumplocale: 로캘 라이브러리에 설정된 내용을 텍스트로 출력하는 명령이다.
• language-string: de_DE, es_ES, fr_FR, it_IT, ja_JP, km_KH, ko_KR, tr_TR, vi_VN, zh_CN, ro_RO 중 하나의 값. 로캘 공유 라이브러리를 덤프할 로캘 언어를 지정한다. language-string이 생략되면 cubrid_locales.txt 파일에 명시된 모든 언어가 주어진다.

다음은 cubrid dumplocale에 대한 [options]이다.

-i, --input-file=FILE¶

로캘 공유 라이브러리 파일 이름을 지정하며, 경로를 포함한다.

-d, --calendar¶

캘린더와 날짜/시간 정보를 추가로 덤프한다.

-n, --numeric¶

숫자 정보를 덤프한다.

-a, --alphabet=l | lower | u | upper | both¶

알파벳과 대소문자 구분 정보를 덤프한다.

--identifier-alphabet=l | lower | u | upper¶

식별자에 대한 알파벳과 대소문자 구분 정보를 추가로 덤프한다.

-c, --codepoint-order¶

코드포인트 값을 기반으로 정렬한 콜레이션 정보를 추가로 덤프한다. 출력되는 정보는 cp, char, weight, next-cp, char, weight이다.

-w, --weight-order¶

가중치 값을 기반으로 정렬한 콜레이션 정보를 추가로 덤프한다. 출력되는 정보는 weight, cp, char이다.

-s, --start-value=CODEPOINT¶

덤프 범위의 시작을 지정한다. -a , --identifier-alphabet , -c, -w 옵션들에 대한 시작 코드포인트이며, 기본값은 0이다.

-e, --end-value=CODEPOINT¶

덤프 범위의 끝을 지정한다. -a, --identifier-alphabet, -c, -w 옵션들에 대한 끝 코드포인트이며, 기본값은 로캘 공유 라이브러리에서 읽은 최대값이다.

-k, --console-conversion¶

콘솔 변환 데이터를 추가로 덤프한다.

-z, --normalization¶

정규화 데이터를 추가로 덤프한다.

다음은 캘린더 정보, 숫자 표기 정보, 알파벳 및 대소문자 정보, 식별자에 대한 알파벳 및 대소문자 정보, 코드포인트 순서에 기반한 콜레이션의 정렬, 가중치에 기반한 콜레이션의 정렬, 데이터를 정규화하여 ko_KR 로캘의 내용을 ko_KR_dump.txt라는 파일에 덤프하는 예이다.

% cubrid dumplocale -d -n -a both -c -w -z ko_KR > ko_KR_dump.txt

여러 개의 옵션을 설정하면 출력되는 내용이 매우 많을 수 있으므로, 파일로 리다이렉션하여 저장할 것을 권장한다.

6단계: CUBRID 관련 프로세스 시작¶

모든 CUBRID 관련 프로세스는 같은 환경 설정을 통해 구동되어야 한다. CUBRID 서버, 브로커, CAS, CSQL 등은 같은 버전의 로캘 바이너리 파일을 사용해야 한다. CUBRID HA, CUBRID SHARD 구성 시에도 마찬가지이다. 예를 들어, CUBRID HA 구성에서 마스터 서버, 슬레이브 서버와 레플리카 서버 등은 환경 설정이 모두 같아야 한다.

서버 프로세스와 CAS 프로세스에 의해 사용되는 로캘의 호환성 여부를 시스템이 자동으로 검사하지 않기 때문에, 두 프로세스 간에 LDML 파일들이 똑같다는 것을 보장해야 한다.

로캘 라이브러리 로딩은 CUBRID 구동의 첫 단계로서, 구동 시에 데이터베이스 구조를 초기화하기 위해 로캘 정보를 요구하는 서버, CAS, CSQL, createdb, copydb, unloaddb, loaddb 프로세스 등은 구동 시점에 로캘 라이브러리를 로딩한다.

로캘 라이브러리 로딩 절차는 다음과 같다.

• 라이브러리 경로가 제공되지 않으면 $CUBRID/lib/libcubrid_<lang_name>.so 파일의 로딩을 시도한다. 이 파일이 발견되지 않으면 하나의 파일 $CUBRID/lib/libcubrid_all_locales.so에서 모든 로캘이 발견된다고 간주한다.
• 로캘 라이브러리가 발견되지 않거나 라이브러리를 로딩하는 동안 오류가 발생하면 CUBRID 프로세스 구동이 종료된다.
• 데이터베이스와 로캘 라이브러리 간 콜레이션 정보가 다르면 CUBRID 프로세스가 구동되지 않는다. 기존 데이터베이스에 로캘 라이브러리의 변경된 콜레이션을 포함하려면, 먼저 cubrid synccolldb 명령을 수행하여 데이터베이스 콜레이션을 로캘 라이브러리에 맞게 동기화한다. 다음으로, 스키마와 데이터를 원하는 콜레이션에 맞게 기존 데이터베이스에 업데이트해야 한다. 자세한 내용은 데이터베이스 콜레이션을 시스템 콜레이션에 동기화를 참고한다.

데이터베이스 콜레이션을 시스템 콜레이션에 동기화¶

CUBRID가 정상적으로 동작하기 위해서는 시스템 콜레이션과 데이터베이스 콜레이션이 같아야 한다. 시스템 로캘은 내장된 로캘과 cubrid_locales.txt 파일을 통해(로캘 설정 참고) 생성한 라이브러리 로캘을 포함한 로캘을 의미하며, 시스템 로캘은 시스템 콜레이션 정보를 포함한다. 데이터베이스 콜레이션 정보는 _db_collation 시스템 카탈로그 테이블에 저장된다.

cubrid synccolldb 유틸리티는 데이터베이스 콜레이션이 시스템 콜레이션과 일치하는지 확인하고, 다를 경우 데이터베이스 콜레이션을 시스템 콜레이션에 동기화하는 유틸리티이다. 하지만, 이 유틸리티는 데이터베이스 서버에 저장된 데이터 자체를 변환하지 않음을 인지해야 한다.

이 유틸리티는 시스템 로캘이 변경된 이후 기존의 데이터베이스 콜레이션 정보를 변경해야 할 때 사용할 수 있다. 단, 사용자가 직접 수동으로 진행해야 하는 작업들이 있다.

동기화 이전에 다음과 같은 작업을 수행한다. cubrid synccolldb -c 명령을 수행하여 생성되는 cubrid_synccolldb_<database_name>.sql 파일을 CSQL을 통해 실행하면 된다.

• ALTER TABLE MODIFY 문을 사용하여 콜레이션을 수정한다.
• 콜레이션을 포함하는 뷰, 인덱스, 트리거, 분할(partition) 등을 모두 제거한다.

cubrid synccolldb를 가지고 동기화를 수행한다. 그리고 아래 작업을 수행한다.

• 뷰, 인덱스, 트리거, 분할 등을 재생성한다.
• 새로운 콜레이션에 맞게 응용 프로그램의 질의문들을 업데이트한다.

이 유틸리티는 데이터베이스를 정지한 상태에서 수행해야 한다.

synccolldb 구문은 다음과 같다.

cubrid synccolldb [options] database_name

• cubrid: CUBRID 서비스 및 데이터베이스 관리를 위한 통합 유틸리티이다.
• synccolldb: 데이터베이스 콜레이션을 시스템 콜레이션(로캘 라이브러리의 내용과 $CUBRID/conf/cubrid_locales.txt 파일을 따름)으로 동기화하는 명령이다.
• database_name: 콜레이션 정보가 로캘 라이브러리의 콜레이션에 맞게 동기화될 데이터베이스의 이름이다.

[options]를 생략하면 시스템과 데이터베이스 간 콜레이션 차이를 출력하고, 동기화 이전에 삭제되어야 할 객체 질의문을 포함하는 cubrid_synccolldb_<database_name>.sql 파일을 생성한다.

다음은 cubrid synccolldb에서 사용하는 [options]이다.

-c, --check-only¶

데이터베이스의 콜레이션과 시스템의 콜레이션을 확인하여 불일치하는 콜레이션 정보를 출력한다.

-f, --force-only¶

데이터베이스에 있는 콜레이션 정보를 시스템에서 설정한 콜레이션과 동일하게 업데이트할 때 업데이트 여부를 질문하지 않는다.

다음의 예는 시스템 콜레이션과 데이터베이스의 콜레이션이 서로 다를 때 어떻게 동작하는지를 보여준다.

먼저 ko_KR 로캘에 대한 로캘 라이브러리를 생성한다.

$ echo ko_KR > $CUBRID/conf/cubrid_locales.txt
$ make_locale.sh -t 64

다음으로 데이터베이스를 생성한다.

$ cubrid createdb --db-volume-size=20M --log-volume-size=20M xdb en_US

스키마를 생성한다. 이때, 각 테이블에 원하는 콜레이션을 지정한다.

$ csql -S -u dba xdb -i in.sql

CREATE TABLE dept (depname STRING PRIMARY KEY) COLLATE utf8_ko_cs_uca;
CREATE TABLE emp (eid INT PRIMARY KEY, depname STRING, address STRING) COLLATE utf8_ko_cs_uca;
ALTER TABLE emp ADD CONSTRAINT FOREIGN KEY (depname) REFERENCES dept(depname);

시스템의 로캘 설정을 변경한다. cubrid_locales.txt에 아무런 값도 설정하지 않으면 데이터베이스에는 내장된 로캘만 존재하는 것으로 간주한다.

$ echo "" > $CUBRID/conf/cubrid_locales.txt

cubrid synccolldb -c 명령을 수행하여 시스템과 데이터베이스 간 콜레이션 차이를 확인한다.

$ cubrid synccolldb -c xdb

----------------------------------------
----------------------------------------
Collation 'utf8_ko_cs_uca' (Id: 133) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
Collation 'utf8_gen_ci' (Id: 44) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
Collation 'utf8_gen_ai_ci' (Id: 37) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
Collation 'utf8_gen' (Id: 32) not found in database or changed in new system configuration.
----------------------------------------
----------------------------------------
There are 4 collations in database which are not configured or are changed compared to system collations.
Synchronization of system collation into database is required.
Run 'cubrid synccolldb -f xdb'

인덱스가 존재한다면 먼저 인덱스를 제거한 후 각 테이블의 콜레이션을 변환하고, 이후 인덱스 생성을 직접 수행해야 한다. 인덱스를 제거하고 테이블의 콜레이션을 변환하는 과정은 synccolldb에서 생성된 cubrid_synccolldb_xdb.sql 파일로 수행할 수 있다. 다음 예에서는 외래 키가 재생성해야 될 인덱스에 해당한다.

$ cat cubrid_synccolldb_xdb.sql

ALTER TABLE [dept] COLLATE utf8_bin;
ALTER TABLE [emp] COLLATE utf8_bin;
ALTER TABLE [emp] DROP FOREIGN KEY [fk_emp_depname];
ALTER TABLE [dept] MODIFY [depname] VARCHAR(1073741823) COLLATE utf8_bin;
ALTER TABLE [emp] MODIFY [address] VARCHAR(1073741823) COLLATE utf8_bin;
ALTER TABLE [emp] MODIFY [depname] VARCHAR(1073741823) COLLATE utf8_bin;

$ csql -S -u dba -i cubrid_synccolldb_xdb.sql xdb

시스템 콜레이션을 데이터베이스에 동기화하기 전에 위의 cubrid_synccolldb_xdb.sql 스크립트 파일을 실행하여 예전의 콜레이션들을 삭제해야 한다.

cubrid synccolldb 명령을 수행한다. 옵션을 생략하면 해당 명령을 수행할 것인지를 확인하는 메시지가 나타나며, -f 옵션을 주면 확인 과정 없이 데이터베이스와 시스템 간 콜레이션 동기화를 수행한다.

$ cubrid synccolldb xdb
Updating system collations may cause corruption of database. Continue (y/n) ?
Contents of '_db_collation' system table was updated with new system collations.

DROP된 외래 키를 다시 생성한다.

$ csql -S -u dba xdb

ALTER TABLE emp ADD CONSTRAINT FOREIGN KEY fk_emp_depname(depname) REFERENCES dept(depname);

칼럼의 문자셋과 콜레이션¶

칼럼의 문자셋과 콜레이션은 문자열 데이터 타입(VARCHAR, CHAR)과 ENUM 타입에 적용된다. 기본적으로 모든 문자열 데이터 타입은 데이터베이스의 기본 문자셋과 콜레이션을 따르는데, 이를 변경하여 지정할 수 있는 방법을 제공한다.

coll_id  coll_name        charset_name    is_builtin  has_expansions  contractions  uca_strength
================================================================================================
0        'iso88591_bin'   'iso88591'     'Yes'        'No'            0             'Not applicable'
1        'utf8_bin'       'utf8'         'Yes'        'No'            0             'Not applicable'
2        'iso88591_en_cs' 'iso88591'     'Yes'        'No'            0             'Not applicable'
3        'iso88591_en_ci' 'iso88591'     'Yes'        'No'            0             'Not applicable'
4        'utf8_en_cs'     'utf8'         'Yes'        'No'            0             'Not applicable'
5        'utf8_en_ci'     'utf8'         'Yes'        'No'            0             'Not applicable'
6        'utf8_tr_cs'     'utf8'         'Yes'        'No'            0             'Not applicable'
7        'utf8_ko_cs'     'utf8'         'Yes'        'No'            0             'Not applicable'
8        'euckr_bin'      'euckr'        'Yes'        'No'            0             'Not applicable'

<data_type> ::= <column_type> [<charset_modifier_clause>] [<collation_modifier_clause>]

<charset_modifier_clause> ::= {CHARACTER_SET | CHARSET} {<char_string_literal> | <identifier> }

<collation_modifier_clause> ::= COLLATE {<char_string_literal> | <identifier> }

CREATE TABLE t1 (s1 VARCHAR (100) CHARSET utf8);

ALTER TABLE t1 CHANGE s1 c1 CHAR(10) COLLATE utf8_en_cs;

SELECT CAST (c1 as VARCHAR(5) COLLATE 'iso88591_en_ci') FROM t1 ORDER BY 1;

SELECT c1 FROM t1 ORDER BY CAST (c1 as VARCHAR(5) COLLATE iso88591_en_ci);

CREATE TABLE t (
    s1 STRING COLLATE utf8_en_cs,
    s2 STRING COLLATE utf8_tr_cs
);

-- insert values into both columns

SELECT s1, s2 FROM t WHERE s1 > s2;

ERROR: '>' requires arguments with compatible collations.

SET NAMES utf8
PREPARE st FROM 'SELECT COLLATION(UPPER(?)) col1, COERCIBILITY(UPPER(?)) col2';
EXECUTE st USING 'a', 'a';

  col1                         col2
===================================
  'utf8_bin'                     -1

CREATE TABLE tbl (e ENUM (_utf8'a', _utf8'b'));

CREATE TABLE t (e ENUM (_utf8'a', _utf8'b') COLLATE utf8_bin);
CREATE TABLE t (e ENUM (_utf8'a', _utf8'b')) COLLATE utf8_bin;

테이블의 문자셋과 콜레이션¶

테이블 생성 구문에 문자셋과 콜레이션을 지정할 수 있다.

CREATE TABLE table_name (<column_list>) [CHARSET charset_name] [COLLATE collation_name]

칼럼의 문자셋과 콜레이션이 생략되면, 테이블의 문자셋과 콜레이션이 사용된다. 테이블의 문자셋과 콜레이션이 생략되면, 시스템의 문자셋과 콜레이션이 사용된다.

다음은 테이블에 콜레이션을 지정하는 예이다.

CREATE TABLE tbl (
    i1 INTEGER,
    s STRING
) CHARSET utf8 COLLATE utf8_en_cs;

칼럼의 문자셋이 지정되어 있고 테이블의 콜레이션이 지정되는 경우, 해당 칼럼의 콜레이션은 칼럼의 문자셋에 대한 기본 콜레이션(<collation_name>_bin)이 지정된다.

CREATE TABLE tbl (col STRING CHARSET utf8) COLLATE utf8_en_ci;

위의 질의문에서 칼럼 col의 콜레이션은 칼럼에 대한 문자셋의 기본 콜레이션인 utf8_bin이 된다.

csql> ;sc tbl

 <Class Name>

  tbl                  COLLATE utf8_en_ci

 <Attributes>

  col                  CHARACTER VARYING(1073741823) COLLATE utf8_bin

문자열 리터럴의 문자셋과 콜레이션¶

문자열 리터럴(string literal)의 문자셋과 콜레이션은 다음과 같은 우선 순위에 따라 정해진다.

1. 문자셋 소개자 또는 문자열의 COLLATE 수정자
2. SET NAMES 문으로 명시한 문자셋과 콜레이션
3. 시스템 문자셋과 콜레이션(DB 생성 시 지정한 로캘에 의한 기본 콜레이션)

SET NAMES [charset_name] [COLLATE collation_name]

SET NAMES utf8;
SET SYSTEM PARAMETERS 'intl_collation=utf8_bin';

SELECT 'a';

SET NAMES utf8;
SELECT 'a';

[charset_introducer]'constant-string' [COLLATE collation_name]

SELECT 'cubrid';
SELECT _utf8'cubrid';
SELECT _utf8'cubrid' COLLATE utf8_en_cs;

SET NAMES utf8 COLLATE utf8_en_ci;
SELECT 'a' COLLATE utf8_en_cs;

표현식의 문자셋과 콜레이션¶

표현식 결과의 문자셋과 콜레이션은 표현식의 인자들로부터 추론된다. 콜레이션 추론 과정은 콜레이션 변환도(coercibility)에 기반하며 이에 관한 자세한 내용은 콜레이션이 서로 다를 때 결정 방식을 참고한다.

모든 문자열 매칭 함수(LIKE, REPLACE, INSTR, POSITION, LOCATE, SUBSTRING_INDEX, FIND_IN_SET 등)와 비교 연산자들(<, >, = 등)에서 콜레이션이 고려된다.

시스템 데이터의 문자셋과 콜레이션¶

시스템 문자셋은 DB 생성 시 지정한 로캘에 의해 정해진다. 시스템의 콜레이션은 항상 시스템 문자셋의 바이너리 콜레이션(<charset>_bin)이다. CUBRID는 iso88591, euckr, utf8 이렇게 3개의 문자셋을 지원하며, 이에 따른 iso88591_bin, euckr_bin, utf8_bin 이렇게 3개의 시스템 콜레이션을 지원한다.

DB 생성 시 지정한 로캘의 영향¶

DB 생성 시 지정한 로캘은 다음에 영향을 끼친다.

• 식별자(identifier)와 대소문자 규칙에서 지원되는 문자(이를 "알파벳"이라고 지칭함)
• 날짜-문자열 변환 함수들에 대한 기본 로캘
• 숫자-문자열 변환 함수들에 대한 기본 로캘
• CSQL에서 콘솔 변환

CREATE TABLE ÈABC;

문자열 리터럴의 입출력¶

문자열 리터럴 데이터는 CUBRID에 다양한 방법으로 입력된다.

• C API interface (CCI)
• 언어 의존적인 인터페이스. JDBC, Perl 드라이버 등
• CSQL - 콘솔 또는 파일로부터 입력

드라이버를 통해 문자 데이터를 받을 때, CUBRID는 이 문자들의 문자셋을 인지할 수 없다. 문자열 리터럴(따옴표로 감싼 문자)에 해당하는 모든 텍스트 데이터는 있는 그대로(raw data) 다루어진다. 문자셋 메타 정보는 응용 클라이언트에 의해 제공되어야 한다. 클라이언트는 SET NAMES 문이나 문자셋 소개자 를 통해 문자셋 정보를 제공할 수 있다.

<consoleconversion type="ISO88599" windows_codepage="28599" linux_charset="iso88599,ISO_8859-9,ISO8859-9,ISO-8859-9" />

콜레이션의 축약과 확장¶

콜레이션의 구축을 위해 축약(contraction)과 확장(expansion)을 지원하며, 축약과 확장은 UTF-8 문자셋 콜레이션에서만 가능하다. 이러한 축약과 확장은 LDML 파일의 콜레이션 설정에서 정의할 수 있는데, 이들의 사용은 로캘 데이터(공유 라이브러리)의 크기와 서버의 성능 모두에 영향을 준다.

문자셋과 콜레이션을 필요로 하는 연산¶

CREATE TABLE t (s_iso STRING CHARSET iso88591, s_utf8 STRING CHARSET utf8);
SET NAMES iso88591;
INSERT INTO t VALUES ('È','È');

-- the first returns 1, while the second does 2
SELECT OCTET_LENGTH(s_iso), OCTET_LENGTH(s_utf8) FROM t;

SET NAMES utf8;
CREATE TABLE t1(col1 CHAR(1));
INSERT INTO t1 VALUES ('Ç');

콜레이션 설정으로 인한 영향¶

s LIKE 'abc%' → s ≥ 'abc' AND s < 'abd' (if using strictly the English alphabet)

s LIKE 'abc%' → s ≥ 'abc' AND s < 'abd' and s LIKE 'abc%' (if using strictly the English alphabet)

콜레이션 정보 보기¶

콜레이션 정보를 보려면 CHARSET(), COLLATION() 및 COERCIBILITY() 정보 함수를 사용한다.

데이터베이스 콜레이션 정보는 db_collation 시스템 뷰 또는 SHOW COLLATION을 통해 확인할 수 있다.

로캘¶

• 기본적으로 DB 생성 시 로캘을 en_US를 사용하면 가장 좋은 성능을 낸다. 영어만 사용한다면 로캘을 en_US로 지정하는 것이 가장 좋다.
• UTF-8 로캘의 사용은 CHAR 타입에 대해 추가적인 저장 공간을 필요로 한다. 고정 길이 문자 타입(CHAR)의 경우 4배까지 늘어나며, EUC-KR의 경우 3배까지 늘어난다.
• 사용자 문자열 리터럴이 시스템과 다른 문자셋과 콜레이션을 가진다면, 질의문은 문자셋과 콜레이션을 설정하기 위해 더 길어질 것이다.
• ASCII 문자가 아닌 문자를 사용자 식별자로 사용하려면 .utf8 로캘을 사용한다.
• UTF-8 문자셋이 설정되면, 시스템 로캘보다는 LDML 로캘을 사용하는 것이 좋다. LDML 로캘은 식별자에 포함된 유니코드 문자의 대소문자 변환을 보장한다.
• 로캘 설정은 문자열 변환 함수에도 영향을 준다. 가장 빈번하게 변환이 이루어지는 로캘을 선택하는 것이 좋다.
• 로캘 설정 시 문자열 상수, 사용자 테이블 칼럼의 문자셋과 콜레이션에 대해 고민하지 않아도 된다. 질의문에서 CAST() 연산자를 사용하여 런타임에 바꿀 수 있으며, "ALTER ... CHANGE" 문을 통해 영구히 바꿀 수 있다. 단, 콜레이션 간에 변환은 같은 문자셋끼리만 가능하다.

CHAR와 VARCHAR¶

• 일반적으로 데이터의 크기 변화가 심할 때는 VARCHAR를 사용한다.
• CHAR 타입은 고정 길이 타입이므로, 영문만 저장하는 경우에도 UTF-8은 4 bytes의 저장 공간을, EUC-KR은 3 bytes의 저장 공간을 필요로 한다.
• 칼럼의 자릿수(precision)는 문자(글리프, 문자 기호)의 개수이다.
• 자릿수를 정한 이후에, 대부분의 사용 시나리오에 따라 문자셋과 콜레이션이 설정되어야 한다.

문자셋 선택¶

• 텍스트가 ASCII가 아닌 문자를 포함하고 있더라도 응용 프로그램이 문자 개수 세기, 문자열 치환 등의 문자열 조작이 필요한 경우에 utf8이나 euckr 문자셋을 사용한다.
• CHAR 타입의 저장 공간을 고려해야 한다.
• CHAR와 VARCHAR 타입에서 INSERT/UPDATE 시 오버헤드가 있다. 각 행에서 문자열의 문자 개수(precision)를 세는 것은 ISO가 아닌 문자셋에서 더 많은 수행 시간을 필요로 한다.
• 질의문 내의 표현식의 문자셋은 CAST() 연산자를 사용하여 변환할 수 있다.

콜레이션 선택¶

• 콜레이션 의존적인 동작(문자열 검색, 정렬, 비교, 대소문자화)이 수행되지 않는다면, 해당 문자셋의 바이너리 콜레이션을 사용한다.
• 표현식의 원래 문자셋과 새로운 콜레이션 사이에서 문자셋이 변경되지 않는다면 콜레이션은 CAST() 연산자, COLLATE 수정자를 사용하여 쉽게 오버라이드할 수 있다.
• 콜레이션은 문자열의 대소문자 구분 규칙을 제어한다.
• 확장이 있는 콜레이션은 더 느리지만 더 유연하며 전체 단어 정렬을 수행한다.

정규화¶

• 응용 클라이언트가 CUBRID에 분해된 형태의 텍스트 데이터를 보낸다면, unicode_input_normalization = yes로 설정하여 CUBRID가 재구성하여 결합된 형태로 다룰 수 있도록 한다.
• 응용 클라이언트가 분해된 형태만 다룰 수 있다면, unicode_output_normalization = yes로 설정하여 CUBRID가 항상 분해된 형식으로 텍스트 데이터를 보내도록 한다.
• 응용 클라이언트가 모든 형식을 알고 있다면, unicode_output_normalization = no인 상태로 둔다.

CAST vs COLLATE¶

• CAST() 연산자는 COLLATE 수정자보다 더 많은 실행 비용이 든다 (문자셋 변환이 발생하면 더 많은 비용이 든다).
• COLLATE 수정자는 질의 실행 과정에서 실행 연산이 추가되지 않기 때문에, COLLATE 수정자를 사용하는 것이 CAST() 연산자를 사용하는 것보다 실행 속도가 더 빠르다.
• COLLATE 수정자는 문자셋이 바뀌지 않을 때만 사용될 수 있다.

LDML 캘린더 정보¶

• 첫 번째 부분은 DATE, DATETIME, TIME, TIMESTAMP 데이터와 문자열 간에 타입을 변환하는 기본 CUBRID 형식을 제공한다. 이 형식은 TO_DATE(), TO_TIME(), TO_DATETIME(), TO_TIMESTAMP(), TO_CHAR() 함수에서 사용된다. 이 형식이 허용하는 원소는 데이터 타입에 의존적이며 TO_CHAR() 함수 (날짜/시간 형식 1)에서 사용된다. 이 형식의 문자열로는 ASCII 문자만 허용된다. 허용되는 크기는 DATE와 TIME 형식에 대해서는 30 바이트 문자, DATETIME과 TIMESTAMP 타입에 대해서는 48 바이트 문자이다.
• <months>는 긴 형식과 축약된 형식 둘 다에 대한 월 이름이 필요하다. 허용되는 크기는 축약된 형식에 대해 15자(또는 60 바이트)이고 긴 형식에 대해 25자(또는 100바이트)이다.
• <days>는 긴 형식과 축약된 형식 둘 다에 대한 요일 이름이 필요하다. 허용되는 크기는 축약된 형식에 대해 10자(또는 40 바이트)이고 긴 형식에 대해 15자(또는 60 바이트)이다.
  • <dayperiods> 서브 트리는 오전/오후 형식의 변형(타입 속성에 따라 달라짐)에 대한 문자열을 정의한다. 허용되는 크기는 10자(또는 40바이트)이다.

월과 요일 이름은 긴 포맷과 축약된 포맷 둘 다 카멜 표기 형식(Camel case case format, 첫 문자는 대문자, 나머지 문자는 소문자)으로 명시되어야 한다. CUBRID는 최대로 허용된 크기를 바이트 단위로 검사한다. 문자의 크기는 UTF-8 문자의 최대 크기에 해당하는 4바이트로만 계산되므로, 100개의 ASCII 문자로만 구성된 월 이름을 설정하는 것이 가능하다(25자 제한은 월 이름의 각 문자가 4바이트로 인코딩된 UTF-8 문자인 경우이다).

LDML 숫자 정보¶

• <symbols> 태그는 정수와 소수 분할 기호 문자와 자릿수 구분 기호 문자를 정의한다. CUBRID는 이 기호들에 대해 ASCII 기호만을 기대하며, 공백 문자는 허용하지 않는다. CUBRID는 3개의 숫자를 그룹지어 자릿수를 구분한다.

LDML 알파벳¶

LDML 알파벳은 로캘의 알파벳에 대한 대소문자 규칙을 정의한다. 'CUBRIDAlphabetMode' 속성은 문자에 대한 데이터의 기본 원본(primary source)을 정의한다. 일반적으로 이 속성은 "UNICODEDATAFILE"로 지정되어야 하는데, 이 값은 CUBRID가 유니코드 데이터 파일($CUBRID/locales/data/unicodedata.txt)을 사용한다는 의미이다.

이 파일은 수정되어서는 안 되며, 특정 문자에 대한 변경은 LDML 파일에서 이루어져야 한다. 이러한 값이 설정되어 있는 경우, 코드포인트 65535까지의 모든 유니코드 문자가 대소문자 정보를 가지고 로딩된다. 'CUBRIDAlphabetMode'에 대해 허용된 다른 값은 "ASCII"로, ASCII 문자만이 소문자, 대문자 또는 대소문자 구분을 하지 않는 문자열 비교 함수에서 사용될 수 있다.

"ASCII"는 CUBRID가 모든 UTF-8 (4바이트) 인코딩 문자를 지원하는 기능에 영향을 주는 것이 아니라, 특정 문자가 대소문자를 구분하는 기능에 포함되지 않도록 제한할 뿐이다.

대소문자 구분 규칙은 선택적이며 문자 정보(UNICODEDATAFILE 또는 ASCII)의 기본 원본 중 가장 우선적으로 적용된다.

CUBRID는 대문자 규칙(<u> 태그) 정의와 소문자 규칙(<l> 태그) 정의를 허용한다. 대문자 규칙과 소문자 규칙 각각은 원본-대상(<s> = source, <d> destination)의 쌍으로 된 구성을 설정한다. 예를 들어, 다음은 문자 "A"의 소문자가 "aa"(2개의 "a" 문자)가 되도록 정의한다.

<l>
    <s>A</s>
    <d>aa</d>
</l>

LDML 콘솔 변환¶

Windows에서 콘솔은 UTF-8 인코딩을 지원하지 않으므로, CUBRID는 UTF-8 인코딩을 원하는 인코딩으로 번역하도록 허용한다. 로캘에 대한 콘솔 변환을 설정한 후에, 사용자는 CSQL 응용 프로그램을 시작하기에 앞서 'chcp' 명령(LDML에서 codepage 속성은 'windows_codepage' 속성과 매칭되어야 한다)을 사용하여 콘솔의 코드페이지를 설정해야 한다. CSQL 입출력 시 변환은 양방향으로 동작하지만, 설정된 코드페이지로서 변환될 수 있는 유니코드 문자로만 제한된다.

<consoleconversion> 원소는 선택적이며 CSQL이 인터렉티브 명령에서 텍스트를 출력(문자 인코딩)하는 방법을 지시하게 한다. 'type' 속성은 변환에 대한 계획(scheme)을 정의한다. 허용되는 값은 다음과 같다.

• ISO: 대상 코드 페이지가 단일 바이트 문자셋인 일반적인 계획(generic scheme)
• ISO88591: ISO-8859-1 문자셋에 대해 미리 준비된 단일 바이트 계획('file' 속성을 필요로 하지 않으며, 있으면 무시됨)
• ISO88599: ISO-8859-9 문자셋에 대해 미리 준비된 단일 바이트 계획(역시 'file' 속성을 필요로 하지 않음)
• DBCS: Double Byte Code-Set. 이것은 대상 코드페이지가 2바이트 문자셋인 일반적인 계획이다.

'windows_codepage'는 CUBRID가 콘솔 변환을 자동으로 활성화하는 Windows 코드페이지에 대한 값이다. 'linux_charset'은 UNIX 계열 시스템의 LANG 환경 변수에서 문자셋 부분과 동일한 값이다. Linux 콘솔에서는 원래의 CUBRID 문자셋을 사용하기를 권장한다.

'file' 속성은 'type' 속성의 값이 "ISO"와 "DBCS"인 경우에만 요구되며 번역 정보($CUBRID/locales/data/codepages/)를 포함하는 파일이다.

LDML 콜레이션¶

콜레이션을 설정하는 것은 CUBRID에서 LDML 로캘을 추가할 때 가장 복잡한 작업이다. UTF-8 코드셋을 가진 콜레이션만 설정될 수 있다. CUBRID는 축약과 확장을 포함하는 UCA(Unicode Collation Algorithm, http://www.unicode.org/reports/tr10/)에 의해 명시된 대부분의 구성을 설정하는 것을 허용하지만, 콜레이션에 대한 속성은 대부분 'settings' 속성을 통해 제어된다.

LDML 파일은 여러 개의 콜레이션을 포함할 수 있다. 콜레이션은 'include' 태그를 사용하여 외부 파일에 의해 포함될 수 있다. 'collations' 태그의 'validSubLocales' 속성은 외부 파일에 의한 외부 콜레이션이 포함될 때 로캘 컴파일을 제어하도록 허용하는 필터이다. 이 속성의 값은 로캘의 리스트 혹은 "*"이 될 수 있으며, "*"을 사용하면 서브트리에 있는 콜레이션이 모든 로캘에 추가된다.

하나의 콜레이션은 'collation' 태그와 서브트리를 사용하여 정의된다. 'type' 속성은 콜레이션에 대한 이름을 나타내므로 CUBRID에 추가될 것이다. 'settings' 태그는 콜레이션의 속성들을 정의한다.

• 'id'는 CUBRID에서 사용되는 (내부의) 숫자 식별자이다. 32부터 255까지의 정수이며 선택적이지만, 할당되지 않은 값의 명시적인 설정을 강력히 권장한다. 콜레이션 명명 규칙을 참고한다.
• 'strength'는 문자열 비교 방법의 척도이다. 콜레이션 속성을 참고한다. 허용되는 값은 다음과 같다.
  • "quaternary": 서로 같은 문자이나 다른 그래픽 기호이면 다르게 비교되지만, 다른 유니코드 코드포인트가 같게 비교될 수 있다.
  • "tertiary": 서로 같은 문자의 그래픽 심볼은 동일하며, 대소문자를 구분하는 콜레이션이다.
  • "secondary": 대소문자 구분 없는 콜레이션이며, 액센트가 있는 문자 사이의 비교 결과가 다르다.
  • "primary": 액센트는 무시되며, 모든 문자는 기본(base) 문자로 비교된다.
• 'caseLevel': 'strength' 값이 "tertiary" 보다 작은 값을 가지는 콜레이션에 대해 대소문자 구분 있는 비교를 가능하게 하는 특별한 설정. 유효한 값은 "on" 또는 "off"이다.
• 'caseFirst': 대소문자 순서. 유효한 값은 "lower", "upper" 그리고 "off"이다. "upper" 값은 대문자가 같은 문자의 소문자보다 앞선다는 의미이다.
• 'CUBRIDMaxWeights': 콜레이션에서 사용자에 의해 정의된(customized) 코드포인트의 개수(또는 최종 코드포인트 + 1). 최대 값은 65536이다. 이 값을 늘리면 콜레이션 데이터의 크기가 늘어난다.
• 'DUCETContractions': 유효한 값은 "use" 또는 "ignore"이다. "use"가 명시되면 ($CUBRID/locales/data/ducet.txt)에 의해 정의된 축약을 콜레이션에서 사용할 수 있다. "ignore"이면 정의된 축약을 무시한다.
• 'TailoringContractions': 위와 같으나 명시된 콜레이션 규칙으로부터 정의되거나 추출된(derived) 축약을 의미한다. 축약을 사용하면 보다 복잡한 콜레이션(더 느린 문자열 비교)이 된다.
• 'CUBRIDExpansions': 허용되는 값은 "use" 또는 "ignore"(기본값)이며 DUCET 파일과 사용자 정의 규칙 둘 다에서 콜레이션 확장을 사용함을 의미한다. 'CUBRIDExpansions'은 콜레이션 속성에서 가장 큰 영향을 준다. 이것을 가능하게 하면 문자열을 비교할 때 여러 단계(콜레이션 세기까지)로 비교하게 되며, 더 "자연스러운" 정렬 순서를 얻을 수 있는 이점이 있지만 콜레이션 데이터를 크게 증가시킨다. 확장을 참고한다.
• 'backwards': "on" 또는 "off" 값이 사용된다. 액센트에 대해 문자열의 끝에서 앞으로 비교되는 "french" 순서를 적용하기 위해 사용된다. 이 값은 'CUBRIDExpansions'이 "use"일 때만 적용된다.
• 'MatchContractionBoundary': "true" 또는 "false". 이 값은 축약이 지정될 때 문자열 매칭에서의 동작을 설정하기 위해 확장과 축약을 가지는 콜레이션에서 사용된다.

콜레이션에 대한 주요 데이터는 DUCET 파일에서 읽혀진다. 이 단계 이후, 콜레이션은 "사용자 정의 규칙(tailoring rules)"에 의해 명시될 수 있다. 이 규칙들은 "<rules>" (LDML)와 "<cubridrules>" (CUBRID 전용)이다.

'cubridrules' 태그는 선택적이며 코드포인트 또는 코드포인트의 범위에 대한 가중치를 명시적으로 설정하는데 사용될 수 있다. 'cubridrules'는 DUCET 파일로부터 기본(primary) 콜레이션을 로딩한 후 '<rules>' 태그에 정의된 UCA 규칙이 적용되기 전에 적용된다. 각 규칙은 '<set>' 태그로 닫힌다. 규칙이 하나의 유니코드 코드포인트만을 언급하는 경우, 코드포인트의 16진수 값을 포함하는 '<scp>' 태그가 제공된다.

모든 사용 가능한 CUBRID 콜레이션은 다음과 같은 CUBRID 규칙을 포함한다.

<cubridrules>
    <set>
        <scp>20</scp>
        <w>[0.0.0.0]</w>
    </set>
</cubridrules>

이 규칙은 20(ASCII 띄어쓰기 문자)으로 시작하는 코드포인트의 가중치(UCA는 콜레이션 원소 당 네 개의 가중치를 정의)가 모두 0으로 설정된다는 것을 나타낸다. '<ecp>' 태그가 없기 때문에 영향을 받는 유일한 코드포인트는 20이다. CUBRID에서 띄어쓰기 문자는 0으로 비교된다. '<set>' 규칙에서 허용되는 태그는 다음과 같다.

• '<cp>': 하나의 코드포인트에 대한 가중치를 설정하는 규칙
• '<ch>': 하나의 문자에 대한 가중치를 설정하는 규칙. 위의 것과 비슷하지만, 코드포인트 대신 이것은 유니코드 문자(UTF-8 encoding)를 기대한다.
• '<scp>': 코드포인트의 범위에 대한 가중치를 설정하는 규칙. 이것이 시작 코드포인트이다.
• '<sch>': 문자의 범위에 대한 가중치를 설정하는 규칙. 이것이 시작 문자이다. 문맥에서, 문자의 순서는 유니코드 코드포인트에 의해 주어진다.
• '<ecp>': 범위 규칙에 대한 끝 코드포인트.
• '<ech>': 범위 규칙에 대한 끝 문자.
• '<w>': 설정할 가중치(단일 값). 가중치는 16진수이다. 각 콜레이션 원소는 점으로 구분되는 네 개의 값을 가지며, 이 값들은 각괄호([])로 감싸진다. 10개의 콜레이션 원소까지 포함할 수 있다.
• '<wr>': 범위에 대해 설정하는 시작 가중치. 선택적으로, 이 태그에는 'step' 속성이 있는데 이는 각 코드포인트 뒤에 증가하는 단계를 설정한다. 기본 단계는 [0001.0000.0000.0000]인데, 이것은 시작 코드포인트에 대한 첫번째 가중치를 설정한 후, 하나의 값이 첫 번째 수준(primary level) 가중치에 추가되고 다음 코드포인트까지 범위로 설정됨을 의미하며, 이 절차는 마지막 코드포인트까지 반복된다.

예:

<cubridrules>
    <set>                            <!-- Rule 1 -->
        <scp>0</scp>
        <ecp>20</ecp>
        <w>[0.0.0.0]</w>
    </set>

    <set>                            <!-- Rule 2 -->
        <scp>30</scp>
        <ecp>39</ecp>
        <wr step="[1.0.0.0][1.0.0.0]">[30.0.0.0][30.0.0.0]</wr>
    </set>

</cubridrules>

Rule 1은, 가중치 0을 포함하여 0부터 20까지의 코드포인트를 설정한다. Rule 2는, 30부터 39(10진수)까지의 코드포인트와 증가하는 가중치를 가진 두 개의 콜레이션 원소의 집합을 설정한다. 이 예에서, 코드포인트 39(문자 "9")는 2개의 콜레이션 원소[39.0.0.0][39.0.0.0]를 보유하는 가중치를 가질 것이다.

'<rules>' 태그 또한 선택적인데, LDML과 UCA 명세에 따라 정해진다. 하위 태그의 의미는 다음과 같다.

• '<reset>': 콜레이션 원소를 지정한다. 이 태그의 정의(다음에 나타나는 '<reset>' 태그까지)에 의해 문자 순서에 대한 규칙들이 조정된다. 축약인지 확장인지에 따라 이 값은 단일 문자셋의 문자이거나 다중 문자셋의 문자가 될 수 있다. 기본적으로, 앵커 뒤에 오는 사용자 정의 규칙(tailoring rules)은 "뒤에(after)" 정렬된다(첫 번째 규칙의 원소는 앵커 뒤에 오며, 두 번째 규칙의 원소는 첫 번째 규칙에 있는 원소 뒤에 정렬됨). 선택적 속성 "before"가 존재하면, <reset> 뒤에 오는 첫 번째 규칙만 앵커 앞에 오는 반면, 두 번째와 이하 규칙들은 일반적인 "뒤(after)"의 정렬(두 번째 규칙에 있는 원소는 첫 번째 규칙에 있는 원소 뒤에 정렬됨)을 재개한다.
• '<p>': 첫 번째 수준(primary level)에서 미리 조정된(tailored) 것 뒤(또는 앞, 앵커가 'before' 속성을 가지는 경우)에 오는 문자.
• '<s>': 두 번째 수준(secondary level)에서 미리 조정된(tailored) 것 뒤(또는 앞, 앵커가 'before' 속성을 가지는 경우)에 오는 문자.
• '<t>': 세 번째 수준(tertiary level)에서 미리 조정된(tailored) 것 뒤(또는 앞, 앵커가 'before' 속성을 가지는 경우)에 오는 문자.
• '<i>': 문자가 이전 것과 동등하게 정렬된다.
• '<pc>', '<sc>', '<tc>', '<ic>': '<p>', '<s>', '<t>', '<i>'와 같지만 문자의 범위를 적용한다.
• '<x>': 확장 문자를 지정한다.
• '<extend>': 확장의 두 번째 문자를 지정한다.
• '<context>': 규칙이 적용되는 문맥을 지정한다. 축약과 확장을 지정하는 변수.

LDML 규칙을 가지고 UCA를 조정하는 것에 대한 보다 자세한 정보는 http://www.unicode.org/reports/tr35/tr35-collation.html를 참고한다.

Footnotes